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REMARKS 

1. Claim Rejections - 35 U.S. C. § 101. The Examiner has rejected Claims 1-5 under 
35 U.S.C. § 101 because the Examiner is of the opinion that the claimed invention is 
directed to non-statutory subject matter. 

Applicant respectfully disagrees. 

Contrary to the assertions of the Examiner, the claims do not merely recite computing 
steps without producing any concrete, useful result and tangible result and/or being 
limited to practical application within the technological arts. The Examiner appears to 
misunderstand the invention by stating that the method for distributing and catching 
metadata, as recited. in the claim, does not output any concrete or useful and tangible 
result, Applicant has clearly stated in the Specification that the useful result of the 
invention is that it "distributes, and effectively caches, information by inserting it into 
file handles that the proxy sends to clients. This information can be used to improve 
performance by eliminating the need for the proxy to generate additional requests to 
the seiner to establish file identity. The distributed information can a 
to improve security, for example, by allowing the proxy to encode into the file handle 
a session key that expires after some amount of time." (page 3, lines 5-12 of the 
Specification) 

Applicant's claim refers to just this method for distributing and caching metadata in 
connection with files maintained in a file system. The file system is a tangible and 
concrete thing, as are the files contained therein. The distribution and caching of 
metadata related to these files is a real-world act. The invention also concerns the 
exchanging of such things as files, objects, and file-object-related information 
between a file server and a client at the intermediary device. Thus, the invention 
requires the movement of information between a file server and a client in connection 
. . with the use of an intermediary device. Applicant fails to see how the moving of files 
between the client and server with the use of an intermediary device does not 
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produce a concrete useful or tangible result. The Examiner appears to be stating that 
any system that manages files is non-statutory. This would mean that a disk drive is 
not statutory. Clearly, this is not the case. 

Further, Applicant's claims use file handles to convey metadata for use by the 
intermediary device and the client. Thus, the structure of data is altered by the 
invention so that the intermediary device and client can better manage the files 
contained in the server. 

As such, the Applicant clearly claims statutory subject matter. The Examiner's 
citation of case law is noted. However, the cases cited regard non-statutory subject 
matter as that which "represents nothing more than an idea or a concept, or as 
simply a starting point for future investigation or research." This is clearly not the 
case here, The Examiner's rejection under 35 U.S.C. § 101 being erroneous, the 
withdrawal thereof is indicated. Applicant therefore respectfully requests that the 
Examiner withdraw this rejection. 

2. Claim Rejection - 35 U.S.C. § 102. Claims 1 - 5 are rejected under 35 U.S.C. § 
102(b) as being anticipated by Xu etal. 

Applicant respectfully disagrees. However, in an effort to clarify the subject matter for 
which the Applicant intends to receive protection, Applicant has amended Claim 1 to 
indicate that the final step requires "using file handles to convey said metadata for 
use by said intermediary device and said client." Thus, Applicant has specifically 
limited the claimed invention to a method that uses file handles to convey metadata. 
This amendment is made for the purpose of expedience and to advance the 
application in the prosecution process, and is not made as a concession that the use 
of IDs for a purpose of conveying metadata is, in fact, found in the art. 

With regard to Xu, Applicant has studied the reference carefully. The section of most 
interest in connection with the claimed invention is found in Xu at column 32, 
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beginning at line 17. To understand the teaching of Xu in connection with its 
relevance to the claimed invention, this entire section, i.e. "management of metadata 
in a secondary data mover 1 ' must be read in context. Beginning at column 32, line 
28, Xu identifies the problem in connection with known file management systems. 
Thus Xu states: 

'The disk block numbers are only valid within a particular file system. Also, access to 
these disk blocks has to go through the underlying logical volume inside the local file 
system, All this information is usually inside the inode structure of the file, and is 
stored as an in-memory vnode inside VFS and in an inode inside UFS. The file 
handle of the request contains the file system ID and the inode number of the target 
file within the file system. Since the inode number is only valid inside a file system 
(UFS) t there is no conventional way for local file systems on a secondary data mover 
to directly use the inode number of a different local file system on Owner. The 
conventional software modules such as VFS, UFS, etc., do not provide sufficient 
infrastructure to permit a secondary data mover to operate on the remote files 
through the same interface as its local files with the file handle." 

As can be seen from the foregoing, Xu has identified limitations of a standard file 
system, the mention of file handles in the foregoing passage is made only to 
indicate the conventional limitations of fife handles. The Examiner is referred to 
Applicant's Specification on page 1 beginning at line 16, in which Applicant describes 
the NFS system and further identifies limitations in connection with such systems. 
Thus, in this regard, the foregoing passage of Xu adds nothing to the state of the art 
than that which is already acknowledged by Applicant and recognized as a limitation 
in the art. 

Xu addresses this problem at column 32, line 44 by stating: 

"A preferred way to solve this problem is to provide a new Shadow File System 
(ShFS) module (314 in FIG. 17) on every secondary data mover. The ShFS module 
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is used to implement one Shadow File System (ShFS) for every local file system on 
each Owner for which we want to provide read-write sharing. A ShFS on a 
secondary data mover shadows a real local file system on an Owner, so that under 
the new structure, the Owners are differentiated from secondary data movers. The 
owner has the real local file systems, such as UFS, while secondary data mover has 
the shadow local file systems. SHFS serves the file read and write requests locally 
on secondary data movers through read-write sharing while other NFS or CIFS 
requests, such as directory operations, file create, and delete, are still forwarded to 
the Owners because the performance gain for such operations usually are not worth 
the effort of exchanging lots of mitigated information." 

It can be seen fronrr the foregoing that the problem recognized by Xu is solved by the 
provision of the Shadow File System. There is nothing in this teaching that concern 
the use of file handles to convey metadata for use by intermediary devices and the 
client. 

Given the context of Xu's invention, Applicant now turns to the disclosure in Xu cited, 
by the Examiner as support for the notion that Xu teaches the use of file handles to 
convey metadata for use by an intermediary device and a client. 

Thus, at column 33, lines 3-8, Xu states: 

"For a request on a remote file, CFS uses the primary id and file system id inside the 
file handle to find the proper ShFS, and use the inode number to find the snode. 
Anything after that should be the same as if the file is owned by a local data mover 
from the CFS point of view." 

The foregoing teaching by Xu is merely a statement of how a conventional the 
system works. That is that "CFS uses the primary id and file system id inside the file 
handle to find the proper ShFS..." In this case all that Xu teaches is that when a 
Shadow File. System is provided, the Shadow File System uses the conventional 
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information contained within the file handle, i.e. the primary id and file system id, 
which are standard in a CFS-type system as look-up information in the Shadow File 
System. Xu does not teach the use of the file handles to convey metadata. Xu only 
teaches the use of standard information already existing in the file handles to support 
a Shadow File System. Thus, Xu does not teach Applicant's invention and a 
rejection for anticipation is erroneous. 

In view of the foregoing, Applicant respectfully requests that the Examiner review the 
Xu reference and withdraw the rejection for anticipation in view of Xu. 

Applicant now addresses the rejection of Claim 3 in view of Xu. Here, the Examiner 
has referred to column 23, lines 47-54 as teaching the use of an intermediary device 
to encode metadata in the form of a session key into a file handle that expires after a 
predetermined period of time. As noted above in connection with Claim 1 , Xu does 
not teach the encoding of metadata into a file handle. Further, even if this were the 
case, Xu does not teach the use of metadata in the form of a session key which is 
encoded into a file handle. The section relied upon by the Examiner for this teaching 
is as follows; 

"Each virtual connection between each Forwarder and Owner is closed due to 
Forwarder inactivity for more than a predetermined amount of time. An attempt is 
made to re-establish a virtual connection over another open TCP connection 
between the Forwarder and the Owner. If this attempt is unsuccessful, Forwarder 
failure is presumed, and all virtual connection involved with this Forwarder are 
explicitly closed by the Owner." 

All that the foregoing section teaches is that a timeout may occur. There is nothing in 
this statement by Xu or anywhere else in Xu that metadata in the form of a session 
key may be encoded into a file handle. v 
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With regard to the rejections of Claims 2, 4, and 5, Applicant makes no comment at 
this time. The Applicant's lack of comment should not be taken as admission, tacit or 
otherwise, that there is any merit in the Examiner's rejection in this regard. 

Should the Examiner deem it helpful, he is encouraged to contact applicant's 
attorney, at (650) 474-8400. 



Respectfully submitted, 




Jeffrey Brill 
Reg. No. 51,198 



Customer No. 22,862 



-14- 



PACE 15/15 * RCVD AT 5/22/2007 6:53:38 PM [Eastern Daylight Time] ; SVR:USPTO-EFXRF-3/17 " DNlS:2738300 - CSlD:B50 474 8401 * DURATION <mm-ss):06-18 



